Conversation
b9bda9c to
4206592
Compare
4206592 to
d93462e
Compare
ff74314 to
27092ae
Compare
|
Hi @wjiayis , thanks for another great contribution! regarding your question: yes, we do need a per-user usage cap. thanks again! |
|
@Junyi-99 No problem! Yea cool, feel free let me know the token limit you decide to have! I feel that having some sort of progress bar would make more sense than the absolute token number. |
|
@wjiayis yeah, a progress bar is much more intuitive than raw numbers. Since models vary in pricing, let's implement a USD-based cap: Since reasoning models make it hard to calculate exact overhead, let’s also add a small disclaimer in the UI mentioning that the usage is an estimate. We'll run this for a bit and adjust based on the results. Also, we should support different limits for different users (e.g., tiered usage caps). What are your thoughts on this tiered pricing approach? Any other suggestions for the plan? Thanks! |
There was a problem hiding this comment.
Pull request overview
This pull request implements user-level token usage tracking to address Issue #58, enabling the system to distinguish between heavy and light users and track LLM token consumption per user. The implementation adds session-based tracking (5-hour windows) and weekly aggregation, with both backend services and a frontend UI to display usage statistics.
Changes:
- Added usage tracking service that records token consumption from OpenAI API responses and stores them in MongoDB with session-based aggregation
- Created new gRPC/REST API endpoints to retrieve current session and weekly usage statistics
- Implemented frontend Usage tab to display token consumption metrics with auto-refresh capability
Reviewed changes
Copilot reviewed 28 out of 29 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| proto/usage/v1/usage.proto | Defines protobuf messages and service for usage tracking API |
| pkg/gen/api/usage/v1/*.go | Generated Go code for usage service (gRPC server, gateway, protobuf messages) |
| webapp/_webapp/src/pkg/gen/apiclient/usage/v1/usage_pb.ts | Generated TypeScript protobuf types for frontend |
| internal/models/usage.go | MongoDB model for LLM session tracking |
| internal/services/usage.go | Core usage tracking service with session management and weekly aggregation |
| internal/api/usage/*.go | API handlers for session and weekly usage endpoints |
| internal/libs/db/db.go | Database index creation for TTL and efficient session lookups |
| internal/services/toolkit/client/completion_v2.go | Integration to capture usage data from OpenAI streaming responses |
| internal/services/toolkit/client/utils_v2.go | Enables usage reporting in stream options |
| internal/services/toolkit/client/client_v2.go | Dependency injection for usage service |
| internal/services/toolkit/client/get_conversation_title_v2.go | Updated to pass userID for usage tracking |
| internal/services/toolkit/client/get_citation_keys.go | Updated to pass userID for usage tracking |
| internal/wire.go, internal/wire_gen.go | Dependency injection wiring for usage service |
| internal/api/server.go, internal/api/grpc.go | Registration of usage service endpoints |
| webapp/_webapp/src/views/usage/index.tsx | Frontend UI component displaying usage statistics |
| webapp/_webapp/src/query/*.ts | React Query hooks and API client functions for usage endpoints |
| webapp/_webapp/src/paperdebugger.tsx | Added Usage tab to main navigation |
| pkg/gen/api/chat/v2/chat.pb.go | Generated code formatting change (import order) |
| internal/api/chat/create_conversation_message_stream_v2.go | Updated to pass userID for usage tracking |
| internal/services/toolkit/client/get_citation_keys_test.go | Test setup updated with usage service dependency |
| go.sum | Updated Go module dependencies |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
@Junyi-99 Sure, a USD-based cap makes a lot of sense!
Are employing a freemium model and charge heavy-usage users? I think it's a great way to monetize PaperDebugger, balancing ease of onboarding for new users, API costs, and returns for sustained development/maintenance. Just off the top of my head, I suggest we could roll this out in 2 phases
Alternatively if we decide not to monetize PaperDebugger, I could block all requests past the free tier usage. |
4ndrelim
left a comment
There was a problem hiding this comment.
Thanks for the good work Jia yi! I haven't yet finished looking through the files, and some parts im not too sure yet, but I will approve first for integration testing on staging and do a deeper review in the meantime before the final PR to main.
@wjiayis If we’re treating PaperDebugger as an independent project, I’m aligned with moving toward a freemium model and charging heavy users. Your plan is quite solid. The 2-phase rollout (observe first, then design tiers based on real data) is very reasonable. I’m good to move forward with Phase 1 and collect usage data first. Then we can refine Free / Lite / Pro based on actual distribution. |
#58